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(54) Configuring method and device 

(57) A device for use in a receiver/decoder operable 
with different conditional access systems, the 
receiver/decoder including means for manipulating data 
received by the receiver/decoder according to a manip- 
ulation protocol which is configurable in dependence on 
the conditional access system, and means for storing 
parameters associated with the manipulation protocol, 
the device comprising: 

means for receiving a command instructing config- 
uration of the manipulation protocol in dependence 
on the conditional access system; 
means for retrieving a parameter from the storing 
means in dependence on the command: and 
means for outputting said parameter to the manipu- 
lation means for use in configuring the manipulation 
protocol, whereby the manipulation means is not 
required to receive all parameters necessary to 
configure the manipulation protocol for all of the 
conditional access systems. 
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Description 

[0001] The present invention relates to a device for 
use in a receiver/decoder, and in particular to a device 
for configuring components of a receiver/decoder in 5 
response to a change in a manipulation protocol or con- 
ditional access system used by the receiver/decoder. 
The invention also relates to a method of configuring a 
receiver/decoder to access data; the data may be in any 
suitable form, such as in the form of a computer pro- 10 
gramme or a television programme. 
[0002] The present invention finds specific application 
in a broadcast digital television system in which 
received signals are passed through a receiver to a 
receiver/decoder and then to a television set. The term 15 
"receiver/decoder" used herein may connote a receiver 
for receiving either encoded or non-encoded signals, for 
example, television and/or radio signals. The term may 
also connote a decoder for decoding received signals. 
Embodiments of such receiver/decoders may include a 20 
decoder integral with the receiver for decoding the 
received signals, for example, in a "set-top box", such a 
decoder functioning in combination with a physically 
separate receiver, or such a decoder including addi- 
tional functions, such as a web browser or a video 25 
recorder. 

[0003] The receiver/decoder may decode a com- 
pressed MPEG-type signal into a television signal for 
the television set. It is controlled by a remote controller 
handset, through an interface in the receiver/decoder. 30 
The receiver/decoder is used to process the incoming 
bit stream, and includes a computer system including a 
variety of (usually computer software) application mod- 
ules which cause the system to perform a variety of con- 
trol and other functions. The term MPEG refers to the 35 
data transmission standards developed by the Interna- 
tional Standards Organisation working group "Motion 
Pictures Expert Group" and in particular but not exclu- 
sively the MPEG-2 standard developed for digital televi- 
sion applications and set out in the documents ISO 40 
13818-1, ISO 13818-2, ISO 13818-3 and ISO 13818-4. 
In the context of the present patent application, the term 
includes all variants, modifications or developments of 
MPEG formats applicable to the field of digital data 
transmission. 45 
[0004] A conditional access system enables an end 
user to access digital television broadcasts from one or 
more broadcast suppliers. In such a conditional access 
system, a Subscriber Authorization System (SAS) man- 
ages access rights to television programmes, available so 
as commercial offers and sold according to different 
modes of commercialisation (subscription mode, pre- 
book mode, impulse mode). The SAS, according to 
those rights and to information received from a Sub- 
scriber Management System (SMS), generates using a ss 
message generator so-called "Entitlement Manage- 
ment Messages" (EMMs) which are broadcast by a 
message emitter via a multiplexer to the 
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receiver/decoder of the subscriber to authorize him/her. 
An EMM may be designated to one subscriber or a 
group of subscribers. Entitlement Control Messages 
(ECMs) are messages sent in relation to scrambled pro- 
grams. An ECM enables a user to descramble a control 
word to obtain the right to descramble a broadcast 
transmission, such as a television programme. During a 
broadcast transmission, the control word typically 
changes every few seconds, and so ECMs are also 
periodically transmitted to enable the changing control 
word to be descrambled. 

[0005] A security module, such as a smartcard, capa- 
ble of decrypting messages relating to commercial 
offers (that is, one or more television programmes sold 
by the broadcast supplier) is inserted in the 
receiver/decoder. Using the receiver/decoder and 
smartcard, the end user may purchase events. 
[0006] It is expected that the receiver/decoder may be 
designed and manufactured by various different manu- 
facturers. It may therefore have various different hard- 
ware designs, and may support one of a number of 
conditional access systems. Indeed, a receiver/decoder 
may support more than one conditional access system. 
In this case, the system used at any one time is selected 
by the subscriber, who is required to insert the correct 
smartcard into the receiver/decoder in order to access 
the chosen conditional access system. 
[0007] When the broadcasts are in the form of MPEG- 
type signals, the data is received in the form of data 
packets of typically 188 bytes within respective types of 
data stream, for example, video data streams, audio 
data streams and teletext data streams. Each packet is 
preceded by a Packet Identifier (PID) of 13 bits, one PID 
for every packet transported in the MPEG data stream. 
Data packets relating to applications, EMMs and ECMs 
typically comprise one or more MPEG sections. 
[0008] Parameters of each conditional access system, 
such as the frequency of signals received from a trans- 
ponder, the values of the PIDs, and any other informa- 
tion necessary to download, for example, an EMM, are 
stored in the memory of the receiver/decoder. This can 
result in a large memory requirement for the 
receiver/decoder, particularly if the receiver/decoder 
supports several different conditional access systems. 
[0009] When one of these parameters is updated, or 
the conditional access system is changed, it is neces- 
sary to update the components of the receiver/decoder 
which perform manipulation of the received datastream 
to enable the end user to access, for example, a televi- 
sion programme broadcast in the datastream. There- 
fore, there may be many applications stored in the 
receiver/decoder which require access to components 
of the receiver/decoder, adding to the complexity of the 
receiver/decoder. Such applications may be required to 
store values of parameters used in the manipulation of 
the received datastream, which can add further to the 
memory requirement of the receiver/decoder. 
[0010] The present invention seeks to solve this and 
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other problems. 

[001 1 J The present invention provides a device for use 
in a receiver/decoder operable with different conditional 
access systems, the receiver/decoder including means 
for manipulating data received by the receiver/decoder s 
according to a manipulation protocol which is configura- 
ble in dependence on the conditional access system, 
and means for storing parameters associated with the 
manipulation protocol, the device comprising: 

w 

means for receiving a command instructing config- 
uration of the manipulation protocol in dependence 
on the conditional access system; 
means for retrieving at least one of the parameters 
from the storage means in dependence on the com- is 
mand; and 

means for outputting said parameter to the manipu- 
lation means for use in configuring the manipulation 
protocol, whereby the manipulation means is not 
required to receive all parameters necessary to 20 
configure the manipulation protocol for ail of the 
conditional access systems. 

[001 2] In one preferred embodiment, the manipulation 
means is provided in the form of a demultiplexer and fil- 25 
ter, in which case the manipulation of the received data 
takes the form of filtering the received data. In this case, 
the term "manipulation protocol" refers to the setting of 
the filter which enables only specific components of the 
received data to be extracted by the receiver/decoder, 30 
and the configuration of the protocol is provided in the 
form of changing the filter to extract different compo- 
nents of the received datastream. 
[0013] As the manipulation means only receives a 
parameter related to one change of the manipulation 35 
protocol, the device (termed the "Conditional Access 
device") can provide an efficient means of configuring 
the manipulation protocol to enable data from different 
conditional access systems to be downloaded. 
[0014] The conditional access device may be 40 
arranged to output the parameter to the manipulation 
means upon receipt of a command instructing output of 
the parameter. As the parameter, which may be used, 
for example, in configuring the manipulation protocol for 
one conditional access system, is sent only after the 45 
receipt of this second command, the retrieval of the 
parameters from the storage means can occur whilst 
the manipulation protocol is configured for a different 
conditional access system, and therefore whilst the 
manipulation means is manipulating data associated so 
with this conditional access system. This can enable 
configuration of the manipulation protocol to be con- 
ducted efficiently. 

[0015] Preferably, the device is capable of receiving 
commands from a configuring application. 55 
[001 6] The parameters may include one or more of an 
identifier of an EMM and an identifier of an ECM. 
[0017] The device may be arranged to receive com- 



mands from a plurality of client applications for a plural- 
ity of parameters. 

[0018] The present invention also provides a 
receiver/decoder including a device as aforesaid, said 
manipulation means arranged to operate under the con- 
trol of the device to manipulate data, and said means for 
storing parameters associated with the manipulation 
protocol. 

[001 9] The present invention also extends to a method 
of configuring a receiver/decoder to access data, the 
receiver/decoder including means for manipulating data 
received by the receiver/decoder according to a manip- 
ulation protocol which is configurable in dependence on 
the conditional access system, and means for storing 
parameters associated with the manipulation protocol, 
the method comprising the steps of :- 

receiving a command instructing configuration of 
the manipulation protocol in dependence on the 
conditional access system; 

retrieving at least one of the parameters from the 
storage means in dependence on the command; 
and 

outputting said parameter to the manipulation 
means for use in configuring the manipulation pro- 
tocol, whereby the manipulation means is not 
required to receive all parameters necessary to 
configure the manipulation protocol for all of the 
conditional access systems. 

[0020] Analogous method features to thejdevice fea- 
tures described above are also provided. 
[0021 ] The present invention also extends to a device 
for use in a receiver/decoder, the receiver/decoder 
including means for storing parameters associated with 
manipulating data received by the receiver/decoder, 
and at least one application or further device, the device 
comprising: 

means for generating an identifier for at least one 
parameter; and 

means for outputting said identifier to said at least 
one application or further device. 

[0022] The identifier can enable the application or fur- 
ther device to access received data, based on the iden- 
tifier. In other words, the application or further device is 
not required to store all parameters for the configured 
manipulation protocol to access retrieved data so that 
the memory of the receiver/decoder can be used effi- 
ciently. 

[0023] The device may be used in a receiver/decoder 
which is operable with different conditional access sys- 
tems, the parameters being associated with manipulat- 
ing data received by the receiver/decoder according to a 
manipulation protocol which is configurable in depend- 
ence on the conditional access system. 
[0024] The device may be arranged to store a plurality 
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of parameters, each having a respective assigned iden- 
tifier. 

[0025] The present invention extends to a 

receiver/decoder including a device as aforesaid, said 
means for storing parameters associated with the 5 
manipulation of data received by the receiver/decoder 
according to a manipulation protocol which is configura- 
ble in dependence on the conditional access system, 
and said application or said further device, 
[0026] In one preferred embodiment, the different con- 10 
ditional access systems are different encryption proto- 
cols, the parameters are decryption parameters, the 
manipulation of data is decryption of encrypted data 
and the manipulation protocol is a decryption protocol. 
Therefore, the present invention also extends to a is 
device for use in a receiver/decoder comprising: 



Figure 3 shows the structure of an Entitlement Man- 
agement Message used in the conditional access 
system; 

Figure 4 shows in detail the structure of the EMM; 

Figure 5 is a schematic diagram of a smartcard; 

Figure 6 is a schematic diagram of an arrangement 
of zones in the memory of the smartcard; 

Figure 7 is a schematic diagram of a PPV event 
description; 

Figure 8 is a functional block diagram of the 
receiver/decoder; 



means for storing decryption parameters for use in 
decryption of encrypted data received by the 
receiver/decoder, the parameters being configura- 
ble to enable decryption of a plurality of different 
encryption protocols; 

means for receiving decryption parameters to con- 
figure at least one decryption protocol; and 
means for passing an identifier of a configured 
decryption protocol to at least one further device or 
application to enable said further device or said 
application to access, in decrypted form, said 
encrypted data based on said identifier, whereby 
said further device or application is not required to 
store all parameters necessary to effect decryption 
of said encrypted data. 

[0027] The present invention also provides a method 
of configuring a receiver/decoder, the receiver/decoder 
including means for storing parameters associated with 
manipulating data received by the receiver/decoder, 
and at least one application or further device, the 
method comprising: 

generating an identifier for at least one parameter; 
and 

outputting said identifier to said at least one appli- 
cation or further device. 

[0028] Analogous method features to the device fea- 
tures described above are also provided. 
[0029] Preferred features of the present invention will 
now be described, purely by way of example, with refer- 
ence to the accompanying drawings, in which:- 

Figure 1 shows the overall architecture of a digital 
television system according to the preferred 
embodiment of the present invention; 

Figure 2 shows the architecture of a conditional 
access system of the digital television system; 



Figure 9 is a schematic diagram of interfaces of the 
receiver/decoder; 

20 

Figure 10 shows certain components of the virtual 
machine and run time engine in more detail; 

Figure 1 1 is a functional block diagram showing the 
25 arrangement of a conditional access device in a 
receiver/decoder; and 

Figure 1 2 shows the architecture of a receiver sys- 
tem for downloading sections from an MPEG data 
30 stream; 

Figure 13 shows steps in a method of configuring a 
demultiplexer and filter to download an EMM; and 

35 Figure 14 shows steps in a method of configuring a 
demultiplexer and filter to download an ECM. 

[0030] Details of a suitable digital interactive television 
system may be found in our co-pending applications 

40 PCT/EP97/02106 - 021 17 to which reference should be 
made, and the disclosures of which are herein incorpo- 
rated by reference. For ease of reference, parts 
described in more detail in the aforementioned specifi- 
cations are generally designated by the reference 

45 numerals used in those specifications. 

[0031] An overview of a digital television broadcast 
and reception system 1000 is shown in Figure 1. The 
invention includes a mostly conventional digital televi- 
sion system 2000 which uses the known MPEG-2 com- 

so pression system to transmit compressed digital signals. 
In more detail, MPEG-2 compressor 2002 in a broad- 
cast centre receives a digital signal stream (typically a 
stream of video signals). The compressor 2002 is con- 
nected to a multiplexer and scrambler 2004 by linkage 

55 2006. The multiplexer 2004 receives a plurality of fur- 
ther input signals, assembles one or more transport 
streams and transmits compressed digital signals to a 
transmitter 2008 of the broadcast centre via linkage 
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2010, which can of course take a wide variety of forms 
including telecom links. The transmitter 2008 transmits 
electromagnetic signals via uplink 2012 towards a satel- 
lite transponder 2014, where they are electronically 
processed and broadcast via notional downlink 201 6 to 5 
earth receiver 2018, conventionally in the form of a dish 
owned or rented by the end user. The signals received 
by receiver 2018 are transmitted to an integrated 
receiver/decoder 2020 owned or rented by the end user 
and connected to the end user's television set 2022. w 
The receiver/decoder 2020 decodes the compressed 
MPEG-2 signal into a television signal for the television 
set 2022. 

[0032] A conditional access system 3000 is connected 
to the multiplexer 2004 and the receiver/decoder 2020, 75 
and is located partly in the broadcast centre and partly 
in the decoder. It enables the end user to access digital 
television broadcasts from one or more broadcast sup- 
pliers. A smartcard, capable of decrypting messages 
relating to commerciaf offers (that is, one or several tel- 20 
evision programmes sold by the broadcast supplier), 
can be inserted into the receiver/decoder 2020. Using 
the decoder 2020 and smartcard, the end user may pur- 
chase events in either a subscription mode or a pay-per- 
view mode. 25 
[0033] An interactive system 4000, also connected to 
the multiplexer 2004 and the receiver/decoder 2020 and 
again located partly in the broadcast centre and partly 
in the decoder, enables the end user to interact with var- 
ious applications via a modemmed back channel 4002. 30 
[0034] The conditional access system 3000 is now 
described in more detail. 

[0035] With reference to Figure 2, in overview the con- 
ditional access system 3000 includes a Subscriber 
Authorization System (SAS) 3002. The SAS 3002 is 35 
connected to one or more Subscriber Management 
Systems (SMS) 3004, one SMS for each broadcast 
supplier, by a respective TCP-iP linkage 3006 (although 
other types of linkage could alternatively be used). 
Alternatively, one SMS could be shared between two 40 
broadcast suppliers, or one supplier could use two 
SMSs, and so on. 

[0036] First encrypting units in the form of ciphering 
units 3008 utilising "mother" smartcards 3010 are con- 
nected to the SAS by linkage 3012. Second encrypting 45 
units again in the form of ciphering units 3014 utilising 
mother smartcards 3016 are connected to the multi- 
plexer 2004 by linkage 3018. The receiver/decoder 
2020 receives a "daughter" smartcard 3020. It is con- 
nected directly to the SAS 3002 by Communications so 
Servers 3022 via the modemmed back channel 4002. 
The SAS sends amongst other things subscription 
rights to the daughter smartcard on request. 
[0037] The smartcards contain the secrets of one or 
more commercial operators. The "mother" smartcard 55 
encrypts different kinds of messages and the "daughter" 
smartcards decrypt the messages, if they have the 
rights to do so. 



[0038] The first and second ciphering units 3008 and 
3014 comprise a rack, an electronic VME card with soft- 
ware stored on an EEPROM, up to 20 electronic cards 
and one smartcard 3010 and 3016 respectively, for 
each electronic card, one (card 3016) for encrypting the 
ECMs and one (card 3010) for encrypting the EMMs. 
[0039] The operation of the conditional access system 
3000 of the digital television system will now be 
described in more detail with reference to the various 
components of the television system 2000 and the con- 
ditional access system 3000. 

Multiplexer and Scrambler 

[0040] With reference to Figures 1 and 2, in the broad- 
cast centre, the digital video signal is first compressed 
(or bit rate reduced), using the MPEG-2 compressor 
2002. This compressed signal is then transmitted to the 
multiplexer and scrambler 2004 via the linkage 2006 in 
order to be multiplexed with other data, such as other 
compressed data. 

[0041] The scrambler generates a control word used 
in the scrambling process and included in the MPEG-2 
stream in the multiplexer 2004. The control word is gen- 
erated internally and enables the end user's integrated 
receiver/decoder 2020 to descramble the programme. 
[0042] Access criteria, indicating how the programme 
is commercialised, are also added to the MPEG-2 
stream. The programme may be commercialised in 
either one of a number of "subscription" modes and/or 
one of a number of "Pay Per View" (PPV) modes or 
events. In the subscription mode, the end user sub- 
scribes to one or more commercial offers, or "bou- 
quets", thus getting the rights to watch every channel 
inside those bouquets. In the preferred embodiment, up 
to 960 commercial offers may be selected from a bou- 
quet of channels. In the Pay Per View mode, the end 
user is provided with the capability to purchase events 
as he wishes. This can be achieved by either pre-book- 
ing the event in advance ("pre-book mode"), or by pur- 
chasing the event as soon as it is broadcast ("impulse 
mode"). In the preferred embodiment, all users are sub- 
scribers, whether or not they watch in subscription or 
PPV mode, but of course PPV viewers need not neces- 
sarily be subscribers. 

[0043] Both the control word and the access criteria 
are used to build an Entitlement Control Message 
(ECM). This is a message sent in relation with a scram- 
bled program; the message contains a control word 
(which allows for the descrambling of the program) and 
the access criteria of the broadcast program. The 
access criteria and control word are transmitted to the 
second encrypting unit 3014 via the linkage 3018. In 
this unit, an ECM is generated, encrypted and transmit- 
ted on to the multiplexer and scrambler 2004. During a 
broadcast transmission, the control word typically 
changes every few seconds, and so ECMs are also 
periodically transmitted to enable the changing control 
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word to be descrambled. For redundancy purposes, 
each ECM typically includes two control words; the 
present control word and the next control word. 
[0044] Each service broadcast by a broadcast sup- 
plier in a data stream comprises a number of distinct 
components; for example a television programme 
includes a video component, an audio component, a 
sub-title component and so on. Each of these compo- 
nents of a service is individually scrambled and 
encrypted for subsequent broadcast to the transponder 
2014. In respect of each scrambled component of the 
service, a separate ECM is required. Alternatively, a sin- 
gle ECM may be required for all of the scrambled com- 
ponents of a service. 

Programme Transmission 

[0045] The multiplexer 2004 receives electrical signals 
comprising encrypted EMMs from the SAS 3002, 
encrypted ECMs from the second encrypting unit 3014 
and compressed programmes from the compressor 
2002. TTie multiplexer 2004 scrambles the programmes 
and transmits the scrambled programmes, the 
encrypted EMMs and the encrypted ECMs as electric 
signals to a transmitter 2008 of the broadcast centre via 
linkage 2010. The transmitter 2008 transmits electro- 
magnetic signals towards the satellite transponder 201 4 
via uplink 2012. 

Programme Reception 

[0046] The satellite transponder 2014 receives and 
processes the electromagnetic signals transmitted by 
the transmitter 2008 and transmits the signals on to the 
earth receiver 2018, conventionally in the form of a dish 
owned or rented by the end user, via downlink 2016. 
The signals received by receiver 2018 are transmitted to 
the integrated receiver/decoder 2020 owned or rented 
by the end user and connected to the end user's televi- 
sion set 2022. The receiver/decoder 2020 demulti- 
plexes the signals to obtain scrambled programmes with 
encrypted EMMs and encrypted ECMs. 
[0047] If the programme is not scrambled, that is, no 
ECM has been transmitted with the MPEG-2 stream, 
the receiver/decoder 2020 decompresses the data and 
transforms the signal into a video signal for transmission 
to television set 2022. 

[0048] If the programme is scrambled, the 

receiver/decoder 2020 extracts the corresponding ECM 
from the MPEG-2 stream and passes the ECM to the 
"daughter" smartcard 3020 of the end user. This slots 
into a housing in the receiver/decoder 2020. The daugh- 
ter smartcard 3020 controls whether the end user has 
the right to decrypt the ECM and to access the pro- 
gramme. If not, a negative status is passed to the 
receiver/decoder 2020 to indicate that the programme 
cannot be descrambled. If the end user does have the 
rights, the ECM is decrypted and the control word 
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extracted. The decoder 2020 can then descrambie the 
programme using this control word. The MPEG-2 
stream is decompressed and translated into a video sig- 
nal for onward transmission to television set 2022. 

5 

Subscriber Management System (SMS) 

[0049] A Subscriber Management System (SMS) 
3004 includes a database 3024 which manages, 

w amongst others, all of the end user files, commercial 
offers, subscriptions, PPV details, and data regarding 
end user consumption and authorization. The SMS may 
be physically remote from the SAS. 
[0050] Each SMS 3004 transmits messages to the 

is SAS 3002 via respective linkage 3006 which imply mod- 
ifications to or creations of Entitlement Management 
Messages (EMMs) to be transmitted to end users. 
[0051 ] The SMS 3004 also transmits messages to the 
SAS 3002 which imply no modifications or creations of 

20 EMMs but imply only a change in an end user's state 
(relating to the authorization granted to the end user 
when ordering products or to the amount that the end 
user will be charged). 

[0052] As described later, the SAS 3002 sends mes- 
25 sages (typically requesting information such as call- 
back information or billing information) to the SMS 
3004, so that it will be apparent that communication 
between the two is two-way. 

30 Entitlement Management Messages (EMMs) 

[0053] The EMM is a message dedicated to an indi- 
vidual end user (subscriber), or a group of end users, 
only (in contrast with an ECM, which is dedicated to one 

35 scrambled programme only or a set of scrambled pro- 
grammes if part of the same commercial offer). Each 
group may contain a given number of end users. This 
organisation as a group aims at optimising the band- 
width; that is, access to one group can permit the reach- 

40 ing of a great number of end users. 

[0054] Various specific types of EMM can be used. 
Individual EMMs are dedicated to individual subscrib- 
ers, and are typically used in the provision of Pay Per 
View services; these contain the group identifies and 

45 the position of the subscriber in that group. So-called 
"Group" subscription EMMs are dedicated to groups of, 
say, 256 individual users, and are typically used in the 
administration of some subscription services. This EMM 
has a group identifier and a subscribers' group bitmap. 

so Audience EMMs are dedicated to entire audiences, and 
might for example be used by a particular operator to 
provide certain free services. An "audience" is the total- 
ity of subscribers having smartcards which bear the 
same system identifier (CS ID). Finally, a "unique" EMM 

55 is addressed to the unique identifier of the smartcard. 
[0055] The structure of a typical EMM is now 
described with reference to Figure 3. Basically, the 
EMM, which is implemented as a series of digital data 
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bits, comprises a header 3060, the EMM proper 3062, 
and a signature 3064. The header 3060 in turn com- 
prises a type identifies 3066 to identify whether the type 
is individual, group, audience or some other type and a 
length identifier 3068 which gives the length of the 
EMM. The EMM proper 3062 of course varies greatly 
according to its type. Finally, the signature 3064, which 
is typically of 8 bytes long, provides a number of checks 
against corruption of the remaining data in the EMM. 

Subscriber Authorization System (SAS) 

[0056] The messages generated by the SMS 3004 are 
passed via linkage 3006 to the Subscriber Authorization 
System (SAS) 3002, which in turn generates messages 
acknowledging receipt of the messages generated by 
the SMS 3004 and passes these acknowledgements to 
the SMS 3004. 

[0057] In overview the SAS comprises a Subscription 
Chain area to give rights for subscription mode and to 
renew the rights automatically each month, a Pay Per 
View Chain area to give rights for PPV events, and an 
EMM Injector for passing EMMs created by the Sub- 
scription and PPV chain areas to the multiplexer and 
scrambler 2004, and hence to feed the MPEG stream 
with EMMs. If other rights are to be granted, such as 
Pay Per File (PPF) rights in the case of downloading 
computer software to a user*s Personal Computer, other 
similar areas are also provided. 
[0058] One function of the SAS 3002 is to manage the 
access rights to television programmes, available as 
commercial offers in subscription mode or sold as PPV 
events according to different modes of commercialisa- 
tion (pre-book mode, impulse mode). The SAS 3002, 
according to those rights and to information received 
from the SMS 3004, generates EMMs for the sub- 
scriber. 

[0059] The EMMs are passed to the Ciphering Unit 
(CU) 3008 for ciphering with respect to the manage- 
ment and exploitation keys. The CU completes the sig- 
nature 3064 on the EMM and passes the EMM back to 
a Message Generator (MG) in the SAS 3002, where the 
header 3060 is added. The EMMs are passed to a Mes- 
sage Emitter (ME) as complete EMMs. The Message 
Generator determines the broadcast start and stop time 
and the rate of emission of the EMMs, and passes these 
as appropriate directions along with the EMMs to the 
Message Emitter. The MG only generates a given EMM 
once; it is the ME which performs cyclic transmission of 
the EMMs. 

[0060] On generation of an EMM, the MG assigns a 
unique identifier to the EMM. When the MG passes the 
EMM to the ME, it also passes the EMM ID. This ena- 
bles identification of a particular EMM at both the MG 
and the ME. 

[0061] Figure 4 illustrates an exemplary EMM (in fact 
a PPV EMM, which is the simplest EMM). The PID 
(Packet identifier) 3170 comprises two portions, the 



actual ID 31 72, and the length parameter for the packet 
3174 (necessary in order that the start of the next 
packet can be identified). The whole PID is expressed in 
just one byte of information, 4 bits being reserved for the 
5 ID, and four for the length. 

Smartcard 

[0062] A daughter, or "subscriber", smartcard 3020 is 
10 schematically shown in Figure 5 and comprises an 8 bit 
microprocessor 110, such as a Motorola 6805 micro- 
processor, having an input/output bus coupled to* a 
standard array of contacts 120 which in use are con- 
nected to a corresponding array of contacts in the card 
75 reader of the receiver/decoder 2020, the card reader 
being of conventional design. The microprocessor 110 
is also provided with bus connections to preferably 
masked ROM 130, RAM 140 and EEPROM 150. 
[0063] The EEPROM 150 contains certain dynami- 
20 cally-created operator zones 1 54, 1 55, 1 56 and dynam- 
ically-created data zones which will now be described 
with reference to Figure 6. 

[0064] EEPROM 150 comprises a permanent "card 
ID" (or manufacturer) zone 151 of 8 bytes which con- 

25 tains a permanent subscriber smartcard identifier set by 
the manufacturer of the smartcard 3020. 
[0065] When the smartcard is reset, the microproces- 
sor 110 issues a signal to receiver/decoder 2020, the 
signal comprising an identifier of the conditional access 

30 system used by the smartcard and data generated from 
data stored in the smartcard, including the card ID. This 
signal is stored by the receiver/decoder 2020, which 
subsequently utilises the stored signal to check whether 
the smartcard is compatible with the conditional access 

35 system being used by the receiver/decoder 2020. 

[0066] The EEPROM 150 also contains a permanent 
"random number generator" zone 152 which contains a 
program for generating pseudo-random numbers. Such 
random numbers are used for diversifying transaction 

40 output signals generated by the smartcard 3020 and 
sent back to the broadcaster. 

[0067] Below the random number generator zone 152 
a permanent "management" zone 153 of 144 bytes is 
provided. The permanent management zone 153 is a 

45 specific operator zone utilised by a program in the ROM 
1 30 in the dynamic creation (and removal) of zones 1 54, 
155, 156... as described below. The permanent man- 
agement zone 153 contains data relating to the rights of 
the smartcard to create or remove zones. 

so [0068] Below the management zone 1 53 is a series of 

"operator ID" zones 154, 155, 156 for operators 1,2 

N respectively. Normally at least one operator ID zone 
will be preloaded into the EEPROM of the subscriber 
smartcard 3020 so that the end user can decrypt pro- 

55 grammes broadcast by that operator. However further 
operator ID zones can subsequently be dynamically 
created using the management zone 1 53 in response to 
a transaction output signal generated via his smartcard 
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3020 by the end user (subscriber), as will subsequently 
be described. 

[0069] Each operator zone 154, 155, 156 is associ- 
ated with one or more "operator data objects" stored in 
the EEPROM 150. As shown in Figure 6, a series of 
dynamically created "operator data" objects 157-165 
are located below the operator ID zones. Each of these 
objects is labelled with: 

a) an "identifier" 1, 2, 3 .... N corresponding to its 
associated operator 1 , 2, 3 ... N as shown in its left 
hand section in Figure 6; 

b) an "ID" indicating the type of object; and 

c) a "data" zone reserved for data, as shown in the 
right hand section of each relevant operator object 
in Figure 6. It should be understood that each oper- 
ator is associated with a similar set of data objects 
so that the following description of the types of data 
in the data objects of operator 1 is also applicable to 
the data objects of all the other operators. Also it 
will be noted that the data objects are located in 
contiguous physical regions of the EEPROM and 
that their order is immaterial. 

[0070] Deletion of a data object creates a "hole" 166 
in the smartcard, that is, the number of bytes that the 
deleted objects had previously occupied are not imme- 
diately occupied. The thus "freed" number of bytes, or 
"hole" are labelled with: 

a) an "identifier" 0; and 

b) an "ID" indicating that the bytes are free to 
receive an object. 

[0071] The next data object created fills the hole, as 
identified by the identifier 0. In this manner the limited 
memory capacity (4 kilobytes) of the EEPROM 150 is 
efficiently utilised. 

[0072] Turning now to the set of data objects associ- 
ated with each operator, examples of the data objects 
are now described. 

[0073] Data object 157 contains an EMM key used for 
decrypting encrypted EMM's received by the 
receiver/decoder 2020. This EMM key is permanently 
stored in the data object 157. This data object 157 may 
be created prior to distribution of the smartcard 3020, 
and/or may be created dynamically when creating a 
new operator zone (as described above). 
[0074] Data object 1 59 contains ECM keys which are 
sent by the associated operator (in this case operator 1 ) 
to enable the end user to decrypt the particular "bou- 
quet" of programs to which he has subscribed. New 
ECM keys are sent typically every month, along with a 
group subscription (renewal) EMM which renews the 
end user's overall right to view the broadcast from (in 
this case) operator 1 . The use of separate EMM and 
ECM keys enables viewing rights to be purchased in dif- 
ferent ways (in this embodiment by subscription and 



individually (Pay Per View)) and also increases security. 
The Pay Per View (PPV) mode will be described subse- 
quently. 

[0075] Since new ECM keys are sent periodically, it is 
5 essential to prevent a user from using old ECM keys, for 
example by switching off the receiver/decoder or re-set- 
ting a clock to prevent expiry of an old ECM key so that 
a timer in the receiver/decoder 2020 could be overrid- 
den. Accordingly operator zone 154 comprises an area 
to (typically having a size of 2 bytes) containing an obso- 
lescence date of the ECM keys. The smartcard 3020 is 
arranged to compare this date with the current date 
which is contained in received ECMs and to prevent 
decryption if the current date is later than the obsoles- 
15 cence date. The obsolescence date is transmitted via 
EMMs, as described above. 

[0076] With reference to Figure 7, the PPV event 
description 167 contains a "session ID" 168 identifying 
the viewing session (corresponding to the program and 
20 the time and date of broadcasting) a "session mode" 
169 indicating how the viewing right is being purchased 
(e.g. in pre-book mode), a "session index" 170 and a 
"session view" 171. 

[0077] In respect of receiving a programme in PPV 

25 mode, the receiver decoder 2020 determines whether 
the programme is one sold in PPV mode. If so, the 
decoder 2020 checks, using the items stored in the PPV 
event description 167 whether the session ID for the 
programme is stored therein. If the session ID is stored 

30 therein, the control word is extracted from the ECM. 
[0078] If the session ID is not stored therein, by means 
of a specific application the receiver/decoder 2020 dis- 
plays a message to the end user indicating that he has 
the right to view the session at a cost of, say, 25 tokens, 

35 as read from the ECM or to connect to the communica- 
tions servers 3022 to purchase the event. Using the 
tokens, if the end user answers "yes" (by means of 
remote controller 2026 (see Figure 2)) the decoder 
2020 sends the ECM to the smartcard, the smartcard 

40 decreases the wallet of the smartcard 3020 by 25 
tokens, writes the session ID 168, the session mode 
169, the session index 170 and the session view 171 in 
the PPV event description 167 and extracts and deci- 
phers the control word from the ECM. 

45 [0079] In the "pre-book" mode, an EMM will be passed 
to the smartcard 3020 so that the smartcard will write 
the session ID 168, the session mode 169, the session 
index 170 and the session view 171 in the PPV event 
description !67 using the EMM. 

so [0080] The session index 1 70 can be set to differenti- 
ate one broadcast from the other. This feature permits 
authorization to be given for a subset of broadcasts, for 
example, 3 times out of 5 broadcasts. As soon as an 
ECM with a session index different from the current ses- 

55 sion index 170 stored in the PPV event description 167 
is passed to the smartcard. the number of the session 
view 171 is decreased by one. When the session view 
reaches zero, the smartcard will refuse to decipher an 
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ECM with a different session index to the current ses- 
sion index. 

[0081] The initial value of the session view depends 
only on the way in which the broadcast supplier wishes 
to define the event to which it relates; the session view 
for a respective event may take any value. 
[0082] The microprocessor 110 in the smartcard 
implements a counting and a comparison program to 
detect when the limit to the number of viewings of a par- 
ticular program has been reached. 
[0083] All of the session ID 168, the session mode 
169, the session index 170 and the session view 171 in 
the PPV event description 167 may be extracted from 
the smartcard using the "call-back" procedure as 
described previously 

[0084] Each receiver/decoder 2020 contains an iden- 
tifier which may either identify uniquely that 
receiver/decoder or identify its manufacturer or may 
classify it in some other way in order to enable it to work 
only with a particular individual smartcard, a particular 
class of smartcards made by the same or a correspond- 
ing manufacturer or any other class of smartcards which 
are intended for use with that class of receiver/decoders 
exclusively 

[0085] In this manner the receiver/decoders 2020 
which have been supplied by one broadcast supplier to 
the consumer are protected against the use of non- 
authorised daughter smartcards 3020. 

Receiver/Decoder 

[0086] With reference to Figure 8, the 

receiver/decoder 2020 comprises a run time engine 
4008 running under the control of a microprocessor and 
a common application programming interface 4054. 
They are installed in every receiver/decoder 2020 so 
that all receiver/decoders 2020 are identical from the 
application point of view. 

[0087] For the purposes of this description, an appli- 
cation is preferably a piece of computer code for control- 
ling high level functions of preferably the 
receiver/decoder 2020. For example, when the end user 
positions the focus of a remote controller on a button 
object seen on the screen of the television set 2022 and 
presses a validation key, the instruction sequence asso- 
ciated with the button is run. 

[0088] An interactive application proposes menus and 
executes commands at the request of the end user and 
provides data related to the purpose of the application. 
Applications may be either resident applications, that is, 
stored in the ROM (or FLASH or other non-volatile 
memory) of the receiver/decoder 2020, or broadcast 
and downloaded into the RAM or FLASH memory of the 
receiver/decoder 2020. 

[0089] Applications are stored in memory locations in 
the receiver/decoder 2020 and represented as resource 
files. The applications can use data files, such as icon 
library files, image files, character font files, colour table 



files and ASCII text files. An interactive application can 
also obtain on-line data by effecting inputs and/or out- 
puts. 

[0090] Referring to Figure 9, the receiver/decoder 
5 2020 includes several interfaces; specifically, a tuner 
4028 for the MPEG signal flow, a serial interface 4030. 
a parallel interface 4032. and two card readers 4036. 
one for a smartcard 3020 forming part of the system 
and one for bank cards (used for making payments, 
w home banking, etc) or another smart card. The 
receiver/decoder also includes an interface 4034 to a 
modemmed back channel 4002 to the television signal 
producer, so that the user can indicate preferences, etc 
back to the television signal (programme) producer. 
15 [0091] The receiver/decoder 2020 contains memory 
divided into a RAM volume, a FLASH volume and a 
ROM volume, but this physical organization is distinct 
from the logical organization. The memory may further 
be divided into memory volumes associated with the 
20 various interfaces. From one point of view, the memory 
can be regarded as part of the hardware; from another 
point of view, the memory can be regarded as support- 
ing or containing the whole of the system shown apart 
from the hardware. 
25 [0092] With reference to Figure 9, the system can be 
regarded as centred on a run time engine 4008 forming 
part of a virtual machine 4007. This is coupled to appli- 
cations on one side (the "high level" side), and, on the 
other side (the "low level" side), via various intermediate 
30 logical units discussed below, to the receiver/decoder 
hardware 4061 . The receiver/decoder hardware can be 
regarded as including the various ports or interfaces as 
discussed above (the interface 2030 for the handset 
2026, the MPEG stream interface 4028, the serial inter- 
ns face 4030, the parallel interface 4032, the interfaces to 
the card readers 4036, and the interface 4034 to the 
modemmed back channel 4002). 
[0093] With reference to Figure 8, various applications 
4057 are coupled to the unit 4007; some of themore 
40 commonly used applications may be more or less per- 
manently resident in the system, as indicated at 4057, 
while others will be downloaded into the system, eg 
from the MPEG data stream or from other ports as 
required. 

45 [0094] The unit 4007 includes, in addition to the run 
time engine 4008, some resident library functions 4006 
which include a toolbox 4058. The library contains mis- 
cellaneous functions in C language used by the engine 
4008. These include data manipulation such as com- 

50 pression, expansion or comparison of data structures, 
line drawing, etc. The library 4006 also includes infor- 
mation about firmware 4060 in the receiver/decoder 
2020, such as hardware and software version numbers 
and available RAM space, and a function used when 

55 downloading a new device 4062. Functions can be 
downloaded into the library, being stored in Flash or 
RAM memory. 

[0095] The run time engine 4008 is coupled to a 
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device manager 4068 which is coupled to a set of 
devices 4064 which are coupled to device drivers 4060 
which are in turn coupled to the ports or interfaces. In 
broad terms, a device driver can be regarded as defin- 
ing a logical interface, so that two different device driv- 5 
ers may be coupled to a common physical port A 
device will normally be coupled to more than one device 
driver; if a device is coupled to a single device driver, the 
device will normally be designed to incorporate the full 
functionality required for communication, so that the 10 
need for a separate device driver is obviated. Certain 
devices may communicate among themselves. 
[0096] Each function of the receiver/decoder 2020 is 
represented as a device 4062. Devices can be either 
local or remote, local devices 4064 include smartcards, is 
SCART connector signals, modems, serial and parallel 
interfaces, a MPEG video and audio player and an 
MPEG section and table extractor. Remote devices 
4066, executed in a remote location, differ from local 
devices in that a port and procedure must be defined by 20 
the system authority or designer, rather than by a device 
and device driver provided and designed by the 
receiver/decoder manufacturer. 
[0097] When a new device 4062 is created, it can be 
installed in existing receiver/decoders 2020 by down- 25 
loading the relevant application 4056 from the broad- 
cast centre. This downloading is performed in the 
receiver/decoder 2020 by an application 4056 which 
checks the hardware and software versions and, if cor- 
rect, loads the software module representing the new 30 
device 4062 and asks a procedure of the library 4006 to 
install the new device code within the firmware (in Flash 
memory). This can provide a flexible and secure instal- 
lation of new functions within the receiver/decoder 2020 
without affecting the rest of the software. 35 
[0098] The device manager 4068 is a common soft- 
ware interface between the application 4056 and the 
specific functions of the receiver/decoder 2020. The 
device manager 4068 controls access to devices 4062, 
declares receipt of an unexpected event, and manages 40 
shared memory. 

[0099] The run time engine 4008 runs under the con- 
trol of the microprocessor and a common application 
programming interface. They are installed in every 
receiver/decoder 2020 so that all receiver/decoders 45 
2020 are identical from the application point of view. 
[0100] The engine 4008 runs applications 4056 on the 
receiver/decoder 2020. It executes interactive applica- 
tions 4056 and receives events from outside the 
receiver/decoder 2020, displays graphics and text, calls so 
devices for services and uses functions of the library 
4006 connected to the engine 4008 for specific compu- 
tation. 

[0101] The run time engine 4008 is an executable 
code installed in each receiver/decoder 2020, and 55 
includes an interpreter for interpreting and running 
applications. Be engine 4008 is adaptable to any oper- 
ating system, including a single task operating system 
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(such as MS-DOS). The engine 4008 is based on proc- 
ess sequencer units (which take various events such as 
a key press, to carry out various actions), and contains 
its own scheduler to manage event queues from the dif- 
ferent hardware interfaces. It also handles the display of 
graphics and text. A process sequencer unit comprises 
a set of action-groups. Each event causes the process 
sequencer unit to move from its current action-group to 
another action-group in dependence on the character of 
the event, and to execute the actions of the new action- 
group. 

[0102] The engine 4008 comprises a code loader to 
load and download applications 4056 into the 
receiver/decoder memory 2028. Only the necessary 
code is loaded into the RAM or Flash memory, in order 
to ensure optimal use. The downloaded data is verified 
by an authentication mechanism to prevent any modifi- 
cation of an application 4056 or the execution of any 
unauthorized application. The engine 4008 further com- 
prises a decompressor. As the application code (a form 
of intermediate code) is compressed for space saving 
and fast downloading from the MPEG-2 transport 
stream or via a built-in receiver/decoder mode, the code 
must be decompressed before loading it into the RAM. 
The engine 4008 also comprises an interpreter to inter- 
pret the application code to update various variable val- 
ues and determine status changes, and an error 
checker. 

[0103] Before using the services of any device 4062, 
a program (such as an application instruction 
sequence) has to be declared as a "client", that is, a log- 
ical access-way to the device 4066 or the device man- 
ager 4068. The manager gives the client a client 
number which is referred to in all accesses to the 
device. A device 4066 can have several clients, the 
number of clients for each device 4066 being specified 
depending on the type of device 4066. A client is intro- 
duced to the device 4066 by a procedure "Device: Open 
Channel". This procedure assigns a client number to 
the client A client can be taken out of the device man- 
ager 4068 client list by a procedure "Device: Close 
Channel". 

[0104] Each device interfaces with an application 
under the control of the device manager 4068 by means 
of one of the three standard procedures, which are com- 
mon to other devices. Information may be passed 
between an application and the device by means of 
tables. The three basic procedures are summarised 
briefly below:- 

1) Device: Call. This command can be used by an 
application for performing synchronous commands 
or data transfer. Execution of the application is sus- 
pended until control is returned when the operation 
by the device driver has completed; this allows 
operations which must be performed in strict 
sequence to be controlled reliably. 
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2) Device: I/O. This command allows asynchronous 
operation. That is, an application can send a 
request for a data transfer or a particular function to 
be performed by the device driver and execution of 
the application can continue while the data transfer 5 
or function is performed by the device driver. 

3) Device: Event. The event trapping function ena- 
bles events to be signalled by the device to an appli- 
cation, and for particular action to be taken by the to 
application in response to the event independently 

of the code the application is executing at the time 
the event is signalled: effectively the application is 
interrupted. Events may be prioritised. Events may 
be used to signal events occurring on the interface, is 
such as a bus reset, or to provide monitoring of 
asynchronous commands, for example by signal- 
ling completion of a requested data transfer. 

[0105] As noted above, the main loop of the run time 20 
engine is coupled to a variety of process sequencer 
units, and when the main loop encounters an appropri- 
ate event, control is temporarily transferred to one of the 
process sequencer units. 

[0106] Referring to Figure 10, the device manager 25 
includes a queue 100 into which events from the 
devices are passed for temporary storage. At suitable 
intervals, the virtual machine sends a signal to this 
queue to extract the first item from it. This event item is 
moved to a queue structure 101 in the virtual machine. 30 
Depending on the priority level of the event item, it is 
inserted into the appropriate one of the 5 queues 0 to 4. 
Event items are extracted from the queue structure 101 
by a queue selector unit 102 under the control of the run 
time engine. 35 
[0107] When an event is selected from the queue 
structure 101, it is passed to a process sequencer unit 
engine 104, which consists of a process sequencer unit 
driver 105 and a set of process sequencer units 106. 
Each process sequencer unit is a set of action-groups 40 
linked together, so that each step from one action-group 
to the next action-group is, in general, dependent on the 
current action-group and the nature of the event. Differ- 
ent process sequencer units have different sizes and 
complexities, including one in which the "next" action- 45 
group, ie the action-group to which the system steps on 
in response to an event, is dependent solely on the 
nature of the event but is independent of the current 
action -group. Also, as is shown at the right-hand side of 
the process sequencer units block, there may be sev- so 
eral copies of a process sequencer unit, ie several iden- 
tical process sequencer units, to deal eg with several 
separate data streams using identical protocols through 
a single port. 

[0108] When an event is selected, it is passed to the 55 
appropriate process sequencer unit. This selects the 
appropriate outlet from the current action-group on the 
process sequencer unit. This results in the appropriate 



next action-group being selected and the actions in that 
action-group being performed, involving eg the sending 
of a message to the device manager or the execution of 
an instruction sequence. Action-groups in the process 
sequencer unit can also send event messages to other 
process sequencer units. 

[01 09] If an instruction sequence is selected, the iden- 
tification of the instruction sequence is sent to a instruc- 
tion sequence selector 107. This obtains the desired 
instruction sequence from a instruction sequence mem- 
ory 108 and passes it to a instruction sequence inter- 
preter 109, which executes the instruction sequence. 
[01 10] The system also includes a filter 110, which is 
loaded with event types eg from the process sequencer 
units 1 06. When an event item is passed from the queue 
1 00 in the device manager to the queue structure 1 0 1 in 
the virtual machine, its type or character is matched 
against the list in the filter 110, and if it is of a type which 
is not recognized, it is rejected. This ensures that if say 
the device manager or the keyboard generates events 
of a type which the virtual machine cannot deal with, 
those events are not passed to the queue structure 101 . 
(If events of this kind were passed to the queue struc- 
ture 101, either they would accumulate in that queue 
structure or they might cause malfunctioning of the 
process sequencer unit engine 104.) 
[01 1 1 ] Thus, it can be seen that our basic system pro- 
vides a platform having considerable flexibility in ena- 
bling an application to communicate with a variety of 
devices. 

Conditional Access Device 

[0112] With reference to Figures 11 and 12, the 
receiver/decoder 2020 includes a conditional access 
device, or CA device, 4100. The CA device 4100 is cou- 
pled via port 4103 to device driver 4102 for the smart- 
card reader 4036 and via port 4105 to device driver 
4104 for a demultiplexer and filter 4502 of the 
receiver/decoder 2020. The CA device is also coupled 
via port 4101 to the device manager 4068 to receive 
commands from, and transmit messages to, applica- 
tions 4056', 4057* stored in the receiver/decoder 2020 
and to access the memory 4024 of the receiver/decoder 
2020 in order, for example, to retrieve data stored 
therein, 

[0113] The CA device 4100 can inform a configuring 
application, for example a resident application 4057\ of 
the conditional access systems supported by the 
receiver/decoder and the conditional access system 
currently being used by the receiver/decoder. Such a 
configuring application is able to change the conditional 
access system currently being used by the 
receiver/decoder 2020. The type of conditional access 
system currently being used by the receiver/decoder is 
written in a buffer in the memory 4024 of the 
receiver/decoder as allocated by the CA device 4100. 
The address of this buffer may be transmitted to the 
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configuring application 4057' via device manager 4068. 
This buffer also contains information regarding the ver- 
sion of the conditional access system currently being 
used by the receiver/decoder, each conditional access 
system supported by the receiver/decoder, and the ver- 
sion of each conditional access system supported by 
the receiver/decoder. 

[0114] A command "CALL_SELECT" enables an 
application program to select the conditional access 
system to be used by the receiver/decoder. The type 
and version number of the conditional access system 
are stored in a memory zone in the memory 4024 of the 
receiver/decoder. The address of the memory zone 
associated with any conditional access system sup- 
ported by the receiver/decoder is also transferable to 
the configuring application 4057' via device manager 
4068. Following receipt of the address of the memory 
zone, the application program sends the address to the 
CA device 4100 in this command. In response to the 
command, the CA device 4100 changes the data stored 
in the buffer in the memory zone of the memory 4024. 
The command returns a signal indicating completion of 
the command, or failure of the command if an EMM or 
ECM is either being loaded by the receiver/decoder 
2020 or being processed by the receiver/decoder 2020. 
[0115] The CA device 4100 enables EMMs to be 
loaded, and ECMs to be demultiplexed for component 
scrambling, for any conditional access system sup- 
ported by the receiver/decoder 2020. 
[0116] With reference to Figure 12, electromagnetic 
signals received by receiver 2018 are transmitted to 
MPEG tuner 4028. The tuner typically scans a range of 
frequencies, stopping only when a carrier frequency is 
detected within that range. The thus detected signals 
are transmitted to demodulator 4500, which demodu- 
lates the signals and transmits them to demultiplexer 
and filter 4502. 

[01171 The demultiplexer and filter 4502 performs 
manipulation of the received datastream so that only the 
required components of the datastream are extracted 
by the receiver/decoder 2020 from the datastream. The 
data manipulation is conducted according to a manipu- 
lation protocol which is configurable in dependence on 
the conditional access system currently being used by 
the receiver/decoder. 

[0118] Data is transported in the MPEG data stream 
in the form of data packets of typically 1 88 bytes within 
respective types of data stream, for example, video data 
streams, audio data streams and teletext data streams. 
Each packet is preceded by a Packet Identifier (PID) of 
13 bits, one PID for every packet transported in the 
MPEG data stream. A programme map table (PMT 
table) contains a list of the different data streams and 
defines the contents of each data stream according to 
the respective PID. Each PMT table is associated with a 
respective broadcast channel. A PID may alert a device 
to the presence of applications in the data stream, the 
PID being identified using the PMT table. The value of 



the PID provides a parameter associated with the 
manipulation protocol. 

[0119] The data packets relating to applications, 
EMMs and ECMs typically comprise one or more MPEG 

5 sections. To enable video packets, audio packets, tele- 
text packets and subtitle packets for a service to be 
downloaded by the receiver/decoder, the correct EMMs 
and ECMs must be provided beforehand. 
[01 20] The manipulation protocol of the demultiplexer 

10 and filter 4502 utilises one or more of typically 8 bytes of 
an MPEG section of the data stream, typically offset 
byte 0 and offset bytes 3 to 9, to filter sections from the 
data stream to enable the desired application, EMM or 
ECM to be downloaded. In dependence on the value of 

is the PID of the application, EMM or ECM to be down- 
loaded, the filter is configurable to enable only that par- 
ticular application, EMM or ECM to be downloaded. 
Following filtering by the demultiplexer and filter 4502, 
an EMM or ECM can be transmitted to the smartcard 

20 3020 inserted in the smartcard reader of the 
receiver/decoder for storage therein. 
[01 21 ] Demultiplexer and filter 4502 is connected to a 
descrambler 4504, which in turn is connected to MPEG 
chip 4506. The chip 4506 in turn is connected to televi- 

25 sion 2022. The demultiplexer and filter 4502 typically 
provides up to 32 outputs connected to RAM volume 
4022 of the memory 4024 of the receiver/decoder 2020. 
[0122] The video packets, audio packets, teletext 
packets and subtitle packets for a service are demulti- 

30 plexed by the demultiplexer 4502, descrambled by the 
descrambler 4504, using a control word extracted from 
an ECM, and transmitted to MPEG chip 4506 for 
processing into signals in a form compatible with the tel- 
evision set 2022. 

35 

EMM Loading 

[0123] The CA device 4100 controls the loading of 
EMMs in the receiver/decoder in dependence on the 
40 conditional access system being, or to be, used by the 
receiver/decoder 2020. 

[01 24] A conditional access table (CAT table) contains 
a list of the different conditional access systems (in the 
form of system identifiers (CS IDs)) and defines the 

45 PIDs 31 70 of the EMMs associated with each CS ID for 
use in the demultiplexing and filtering of data. The CAT 
table is downloaded regularly from the datastream and 
stored in a memory zone of the memory 4024 of the 
receiver/decoder 2020. The CAT table may be updated 

so at any time, for example, if the PIDs of any of the EMMs 
identified thereby has changed because the EMM pack- 
ets are being transmitted from a new transponder. 
[01 25] When an updated CAT table has been down- 
loaded in the receiver/decoder 2020, an application, 

55 using a command "CALL__SET_CAT", can inform the 
CA device 4100 of the presence of the new CAT table. 
[0126] The list of PIDs for each system is used in the 
configuration of the demultiplexer and filter 4502 of the 
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receiver/decoder 2020 so that, for the conditional 
access system being used by the receiver/decoder, the 
correct data manipulation protocol is used to enable the 
correct EMMs to be transmitted to, for example, the 
smartcard 3020. Therefore, when there is a change in 
either: 

(i) the CAT table; or 

(ii) the conditional access system being used by the 
receiver/decoder; 

the demultiplexer and filter 4502 is updated to change 
the data manipulation protocol. 

[0127] Upon receipt of a command 

"CALL_SETJNFO" from an application, the CA device 
4100 identifies the conditional access system used by 
the receiver/decoder and generates, using the CAT 
table stored in the memory 4024, a table comprising the 
values of the PIDs of the EMMs of that conditional 
access system. 

[0128] When the CA device 4100 receives a com- 
mand "IO_EMM_START" from an application, the thus- 
generated table is transmitted to the demultiplexer and 
filter driver 4104 to configure the demultiplexer and filter 
4502 accordingly so that the correct manipulation proto- 
col is used. The command returns a signal to the appli- 
cation 4057' indicating completion of the command, or 
failure of the command if an EMM is currently being 
downloaded or if no conditional access system has 
been set using the CA_SELECT command. 
[0129] The above operation of the CA device is sum- 
marised in Figure 13. 

[0130] First, in step S100, the CA device receives 
command "CALL_SET_CAT" via port 4101 from an 
application which informs the CA device of a new CAT 
table in the memory 4024 of the receiver/decoder 2020. 
From the CAT table, the CA device is able to access a 
list of all of the different conditional access systems (in 
the form of system identifiers (CS IDs)) supported by 
the receiver/decoder 2020 and lists of the PIDs of the 
EMMs associated with each CS ID. These lists provide 
parameters associated with the manipulation protocol of 
the demultiplexer and filter 4502. 
[0131] Next, in step S102, the CA device receives 
command "CALL_SETJNFO" via port 4101 from an 
application, which identifies the conditional access sys- 
tem used by the receiver/decoder and, in response, the 
CA device generates in step S104, using the CAT table, 
a table comprising the values of the PIDs of the EMMs 
of that conditional access system only as retrieved from 
the memory 4204 via port 4101 . 
[0132] Finally, in step S106, the CA device receives 
command "IO_EMM_START via port 4101 from an 
application, and in step S108 the table generated in 
step S104 is transmitted to the demultiplexer and filter 
driver 4104 via port 4105 to configure the manipulation 
protocol for the demultiplexer and filter 4502, that is, to 
configure the filter of the demultiplexer and filter 4502, 



so that only the EMMs of that conditional access system 
can be downloaded by the receiver/decoder 2020. 
[0133] In the above operation, only those parameters 
necessary to configure the manipulation protocol are 

5 transmitted to the demultiplexer and filter 4502. 

[01 34] With respect to the subsequent handling of the 
downloaded EMMs, event "EVENT_CA_EMM" from the 
CA device 41 00 is arranged to signal to an application 
the reception by a smartcard of an EMM transmitted 

w thereto, and provide a parameter block addressed to an 
application which contains the address of the stored 
EMM and information provided by the smartcard driver 
4102 via port 4103, this information depending on the 
conditional access system being used by the 

15 receiver/decoder 2020. 

[0135] Event "EVENT_CA_EMM_ ERROR" is 
arranged to signal the rejection by a smartcard of an 
EMM transmitted thereto, for example, if the smartcard 
does not have the right to store the EMM, and provide a 

20 data block addressed to the application which contains 
information provided by the smartcard, this information 
depending on the conditional access system being used 
by the receiver/decoder. 

[0136] Alternatively, an "applicative" EMM (that is, an 
25 EMM transmitted in respect of an application) may be 
stored in the memory of the receiver/decoder, for exam- 
ple, in order to verify that the application 4056 is func- 
tioning correctly. Event "EVENT_CA_APPlEMM M is 
arranged to signal to an application the reception of an 
30 applicative EMM. The event provides a data block 
addressed to the application which contains the 
address of the stored EMM. 



35 



ECM Loading 



[0137] The CA device 4100 manages the demultiplex- 
ing of ECMs for component descrambling. 
[0138] Using a command "CALL_ADD_ECM" an 
application provides the CA device 4100 with the PID of 

40 an ECM to be loaded by the receiver/decoder 2020 as 
specified by the PMT table. The PMT table is stored in 
the memory 4024, which contains a list of the different 
data streams and defines the contents of each data 
stream according to the respective PID. The PID is pro- 

45 vided together with any other information relating to the 
conditional access system selected using the 
CALL_SELECT command necessary to manage the 
ECM. Such information typically includes an identifica- 
tion of the conditional access system, the session 

so number of a PPV event, and the index number of a PPV 
event. 

[0139] The CA device 4100 assigns an identifier 
"DESCRJD" for the PID of the ECM and returns to the 
application, via device manager 4068, an address of the 
55 memory zone in which the DECRJD for the PID of the 
ECM is to be found. An ECM PID corresponds to a 
unique DESCRJD. Alternatively, the CA device may 
return to the application, via device manager 4068, an 
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error message indicating that no conditional access 
system has been selected, the PID has been transmit- 
ted previously to the device, or that a predetermined 
maximum number of DESCRJDs has been reached. 
[01 40] The CA device 41 00 also prepares to return the s 
value of the PID to the demultiplexer and filter driver 
4104 to enable the ECM to be received by the 
receiver/decoder. 

[01 41 ] The application subsequently transmits a com- 
mand "CALL_SERVICE_SET_PID M to the CA device 10 
4100 to identify the addresses in the memory of the 
receiver/decoder of the PIDs of the video, audio, subtitle 
and teletext packets of the event to be demultiplexed. 
These values of these PIDs can be linked to the 
DESCRJD identifier previously assigned to the PID of is 
the ECM. The identifier can then be used by the applica- 
tion to identify the components of the datastream with- 
out the need for the application to receive values for all 
of these components. 

[0142] Demultiplexing and filtering of the video, audio, 20 
subtitle and teletext packets does not commence until 
the application transmits a command 
" C A LL_S E R V I C E_STA RT" to the CA device 4100. 
Upon receipt of this command, the CA device transmits 
to the demultiplexer and filter driver 4104 the value of 25 
the PID of the ECM and the data packets of the event. 
The ECM is demultiplexed, filtered and transmitted to 
the smartcard 3020 for storage therein. The control 
word for the descrambling of the components of the 
event is extracted from the ECM and transmitted to the 30 
descrambler 4504. 

[0143] The above operation of the CA device is sum- 
marised in Figure 14. 

[0144] First, in step S200, the CA device receives 
command "C A LL_AD D_E CM" via port 4101 from an 35 
application, which provides the CA device 4100 with the 
PID of an ECM to be loaded by the receiver/decoder 
2020 as specified by the PMT table, stored in the mem- 
ory 4024 of the receiver/decoder. The CA device 4100 
assigns an identifier DESCRJD to the PID of the ECM 40 
and returns the address of the memory zone of the 
identifier to the application. 

[0145] Next, in step S202, the CA device receives 
command "CALL_SERVICE_SET_PID" from an appli- 
cation, which provides the CA device 4100 with the 45 
addresses in the memory of the receiver/decoder of the 
PIDs of the video, audio, subtitle and teletext packets of 
the event to be demultiplexed so that the values of the 
PIDs can be retrieved by the CA device 4100. The val- 
ues of the PIDs are linked to the DESCRJD assigned to so 
the PID of the ECM. 

[0146] Finally, in step S204, the CA device receives 
command M CALL_SERVICE_START' via port 4101 
from an application, and in step S206 the CA device 
4100 transmits to the demultiplexer and filter driver 55 
4104 the value(s) of the PID(s) of the ECM and the 
packets of the event. 

[0147] Again, in the above operation, only those 
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parameters necessary to configure the manipulation 
protocol are transmitted to the demultiplexer and filter 
4502. In addition, a single identifier DESCRJD is 
assigned to the PIDs of the ECM and the various differ- 
ent types of data packet, to which the application may 
subsequently refer without reference to all of the param- 
eters linked thereto. 

[0148] As described above, the CA device 41 00 man- 
ages the loading of EMMs and the demultiplexing of 
ECMs for component descrambling for any conditional 
access system supported by the receiver/decoder 
2020. For each of these management functions of the 
CA device 4100, the same commands are sent by any 
application to the CA device 4100; with respect to EMM 
loading, the CA device receives commands 
"C ALL_S ET_C AT" , "C ALL_SET J NFO" and 
"CALL_EMM_START" from any application irrespective 
of the conditional access system to be used, and, with 
respect to ECM management, the CA device receives 
commands "CALL_ADD_ECM" 
"CALL_SERVICE_SET_PID" and 
" C ALL_S E RV I C E_STA RT" from any application, again 
irrespective of the conditional access system to be 
used. The EMM loading and ECM management only 
commences after the receipt of the final command; 
there is no need to update, for example, the demulti- 
plexer and filter 4502 until a command to start EMM 
loading is received by the CA device 41 00. There is also 
no need to transmit all of the parameters listed in the 
CAT table and PMT table to the demultiplexer and filter 
4502; only the parameters associated with the required 
manipulation protocol are transmitted to the demulti- 
plexer and filter 4502. Similarly, there is no need to 
transmit all of the parameters in the PMT table to an 
application, only a DESCRJD identifier of the parame- 
ters. 

[0149] It will be understood that the present invention 
haseen described above purely by way of example, and 
modifications of detail can be made within the scope of 
the invention. 

[01 50] Each feature disclosed in the description, and 
(where appropriate) the claims and drawings may be 
provided independently or in any appropriate combina- 
tion. 

[01 51 ] In the aforementioned preferred embodiments, 
certain features of the present invention have been 
implemented using computer software. However, it will 
of course be clear to the skilled man that any of these 
features may be implemented using hardware. Further- 
more, it will be readily understood that the functions per- 
formed by the hardware, the computer software, and 
such like are performed on or using electrical and like 
signals. 

Claims 

1 . A device for use in a receiver/decoder operable with 
different conditional access systems, the 



14 

BNSDOCID:<EP 0935382A1> 



EP 0 935 382 A1 



28 



receiver/decoder including means for manipulating 
data received by the receiver/decoder according to 
a manipulation protocol which is configurable in 
dependence on the conditional access system, and 
means for storing parameters associated with the 5 
manipulation protocol, the device comprising: 

means for receiving a command instructing 
configuration of the manipulation protocol in 
dependence on the conditional access system; 10 
means for retrieving a parameter from the stor- 
ing means in dependence on the command; 
and 

means for outputting said parameter to the 
manipulation means for use in configuring the 15 
manipulation protocol, whereby the manipula- 
tion means is not required to receive all param- 
eters necessary to configure the manipulation 
protocol in dependence on all of the conditional 
access systems. 20 

2. A device according to Claim 1 , arranged to output 
said parameter to the manipulation means upon 
receipt of a command instructing output of said 
parameter. 25 



the conditional access system; 
retrieving a parameter from the storing means 
in dependence on the command; and 
outputting said parameter to the manipulation 
means for use in configuring the manipulation 
protocol, whereby the manipulation means is 
not required to receive all parameters neces- 
sary to configure the manipulation protocol in 
dependence on all of the conditional access 
systems. 

9. A method according to Claim 8, wherein said 
parameter is output upon receipt of a command 
instructing output of said parameter. 

10. A method according to Claim 8 or 9, wherein com- 
mands are received from a configuring application. 

11. A method according to any of Claims 8 to 10, 
wherein the parameters include an identifier of an 
EMM. 

12. A method according to any of Claims 8 to 11, 
wherein the parameters include an identifier of an 
ECM. 



A device according to Claim 1 or 2, wherein the 
device is capable of receiving commands from a 
configuring application. 

A device according to any preceding claim, wherein 
the parameters include an identifier of an EMM. 

A device according to any preceding claim, wherein 
the parameters include an identifier of an ECM. 

A device according to any preceding claim, 
arranged to receive requests from a plurality of cli- 
ent applications for a plurality of parameters. 

A receiver/decoder including a device according to 
any preceding claim, said manipulation means 
arranged to operate under the control of the device 
to manipulate data and said means for storing 
parameters associated with the manipulation proto- 
col. 

A method of configuring a receiver/decoder to 
access data, the receiver/decoder including means 
for manipulating data received by the 
receiver/decoder according to a manipulation pro- 
tocol which is configurable in dependence on the 
conditional access system, and means for storing 
parameters associated with the manipulation proto- 
col, the method comprising the steps of :- 

receiving a command instructing configuration 
of the manipulation protocol in dependence on 
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13. A method according to any of Claim 8 to 12, 
wherein requests are received from a plurality of cli- 
ent applications for a plurality of parameters. 

14. A device for use in a receiver/decoder.the 
receiver/decoder including means for storing 
parameters associated with manipulating data 
received by the receiver/decoder, and at least one 
application or further device, the device comprising; 



means for generating an identifier for at least 
one parameter; and 

means for outputting said identifier to said at 
40 least one application or further device. 

15. A device according to Claim 14, the 
receiver/decoder being operable with different con- 
ditional access systems, said parameters being 
45 associated with manipulating data received by the 
receiver/decoder according to a manipulation pro- 
tocol which is configurable in dependence on the 
conditional access system. 

50 16. A device according to Claim 14 or 15, arranged to 
store a plurality of parameters, each having a 
respective assigned identifier. 

17. A receiver/decoder including a device according to 
55 any of Claims 14 to 16, and said means for storing 
parameters associated with the manipulation of 
data received by the receiver/decoder, and said fur- 
ther device or said application. 
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18. A method of configuring a receiver/decoder, the 
receiver/decoder including means for storing 
parameters associated with manipulating data 
received by the receiver/decoder, and at least one 
application or further device, the method compris- 5 
ing: 

generating an identifier for at least one param- 
eter; and 

outputting said identifier to said at least one 10 
application or further device. 

19. A method according to Claim 18, further comprising 
storing a plurality of parameters, each having a 
respective assigned identifier. 15 
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Fig.2. 
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Fig.5. 
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Fig.6. 
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